Обобщенные модели служб безопасности

Этот раздел представляет несколько эталонных моделей, которые помогают понять и определяют область действия и функциональные возможности cпецификации безопасности. Здесь также представлен общий обзор служб безопасности и их механизмов.

 

1. Защищенные соединения и интерфейсы ATM

Агент безопасности согласовывает параметры и предоставляет для виртуального канала службы безопасности. Рисунок 1 показывает самый простой случай, в котором агенты безопасности расположены в конечной системе ATM. В этом случае, подключение конечной системы осуществляется посредством “интерфейса пользователь-сеть” (User-Network Interface UNI ). Для каждого виртуального канала, установленного системой, агент безопасности (Security Agent SA) в этой системе:

· Определяет,какие службы безопасности, если они есть, должны быть использованы для виртуального канала,

· Cогласовывает параметры служб с другим SA того же уровня,

· Подтверждает подлинность и заменяет ключи, в случае необходимости,

· Применяет требуемую службу(ы) безопасности к виртуальному каналу.

 

 

Рисунок 1.Защищенные соединения агентов защиты в конечной системе

Установление того,какая служба безопасности необходима для виртуального канала являются содержанием стратегии безопасности, которая лежит вне контекста этого документа. Существование и природа любого взаимодействия между приложением конечной системы и ее локальным агентом защиты - также лежат вне этого документа.

Согласование параметров служб с агентами защиты того же уровня происходит c помощью обмена информацией безопасности (SECURITY INFORMATION EXCHANGE SIE),общий обзор которого представлен в разделе 3 . Посредсвом согласования параметров, агенты безопасноти устанавливают одно защищенное соединение для каждой службы, которую нужно предоставить. Так, если требуется удостоверение подлинности, конфиденциальность, и целостность данных для данного виртуального канала, то имеются три защищенных соединения между агентами одного уровня, по одному для каждой службы. Защищенное соединение – это те служебные данные (генерируемые например, криптогафическим алгоритмом) управляющие структурой службы безопасности, предоставляемой для данного виртуального канала. Если требуется, удостоверение подлинности и обмен начальными ключами происходит также в течение согласования параметров службы. Ключевой обмен требуется для поддержки конфиденциальности и целостности служб данных. Согласование параметров поддерживает обмен мастер-ключами связи (используемые ключи генерируют "сеансовый" ключ будущего соединения, если необходимо) и начальными сеансовыми ключами связи для шифрования и криптогафических контрольных сумм.

Приложения служб для виртуального канала меняются согласно упраляющей службе безопасности. Для удостоверения подлинности, служба действует в течение согласования параметров. Для конфиденциальности, шифрование применяется к ячейкам неслужебных данных(той информации которую собственно и нужно передать т.е. полезной нагрузки), с поддержанием криптогафического состояния и модификаций запроса сеансового ключа, снабжаемого (дополнительно) через потоки OAM. Для целостности данных, криптогафическая контрольная сумма и порядковый номер (дополнительный) присоединяются к модулям данных (SDUs) службы AAL5.

Замечание: модель "конечная система - конечная система" на рисунке 1 - единственная, которая применяется для служб безопасности целостности данных, потому что целостность данных реализована в AAL.

 

Рисунок 2.Защищенные соединения между SA в коммутаторе и SA в конечной системе.

Рисунок 2 показывает другую конфигурацию SA. На этом рисунке один SA расположен в пределах АТМ конечной системы, а другой в пределах коммутатора АТМ. Полная операция – та же, что и показывалась на рисунке 1: определение (агентов), согласование (протоколов) и применение служб безопасности через соединение безопасности между агентами безопаснасти одного уровня. Однако, рисунок 2 выделяет некоторые возможности и взаимодействия, которые не показаны очевидным образом на рисунке 1. Рисунок 2 предполагает возможность наличия у SA3 “firewall”, что обеспечивает службами безопасности одного или более пользователей в сети “позади” firewall. Наконец, предполагается, что коммутаторы, которые оснащены агентами защиты будут выполнять функции не свойственные коммутаторам.Например, шифрование полезной нагрузки ячейки данных.

Агент защиты в пределах коммутатора может работать как proxу для одной или более конечных систем. В выщеупомянутом случае, удаленный SA определяет (подтверждает подлинность) SA в коммутаторе (то есть, идентификатор SA предполагается не располагается в конечной системе) конечной системы.

Заметьте, что служба безопасности применяется только в той части VC между SA одного уровня,которые поддерживают эту службу. Если посмотреть на рисунок 2,то видно,что отсутствует какая-либо защита виртуального канала между левой конечной системой и коммутатором,содержащим агент безопасности. Вопросы о приемлимости этого факта являются содержанием стратегии защиты. Однако, как покажут следующие разделы,возможно обеспечить различные уровни защиты для различных частей VC.

 

2.2 Составные защищенные соединения и вложения

Рисунок 3 показывает, что в установленную службу безопасности данного виртуального канала может быть включена более чем одна пара SA или более чем одно соединение безопасности. На этом рисунке SA1 и SA4 имеют соединение безопасности, в котором они обеспечивают удаленную аутентификацию. Независимо от этого, SA2 и SA3 устанавливают соединение, при сохранении конфиденциальности. Эти два соединения независимы.

Установки других служб SA1 и SA4 не знают, и даже не имеют возможности выяснить, какие службы безопасности могут поддерживают другие агенты. Эта независимость позволяет одновременно реализовываться многочисленным (и различным) стратегиям защиты для различных частей сети.

Однако существуют некоторые ограничения, на то, что можно было бы назвать топологией соединения безопасности; они следуют из мехинизмов, выбранных для связи служб безопасности, и форм соединений безопасности. Топологией предполагается, что путям различных соединений безопасности позволяется перекрываться на виртуальном канале.

Рисунок 3 показывает один тип перекрытия, которое предусматривает вложение. Мы можем говорить, что “сегмент” VC [SA2, SA3] содержится в [SA1, SA4] сегменте.

Другие допустимые отношения среди соединений не перекрываются. Если, вместо того, что изображено, соединения были бы между SA1 и SA2, SA3 и SA4, то сегменты [SA1, SA2] и [SA3, SA4] не имели бы никакого перекрытия, и соединения были бы допустимы.

Точно так же, если существуют соединения между SA1 и SA3, SA3 и SA4, то сегменты [SA1, SA3] и [SA3, SA4] не имели бы никакого перекрытия, и соединения были бы допустимы. Вложение – единственное допустимое перекрытие.Службы одновременно не будут поддерживать соединения между SA1 и SA3, SA2 и SA4, например.

В дополнение к этим топологическим ограничениям, имеется также предел на уровнь вложенности равный 16.

 

Рисунок 3.Два вложенных защищенных соединения.

 

3. Обмен информацией безопасности

Существуют три метода обмена информацией, которые могли бы быть включены в установление и поддержание безопасной связи: метод,основанный на сигнализации SME,внутриполосный SME, обмен защищенными OAM ячейками.Любая комбинация из этих трех методов безопасного обмена информации может использоваться для поддержки любого защищенного соединения. Протокол обмена сообщений защиты (SME) используется для соответствия параметров служб безопастности, установлении защищенных соединений,аутентификации SA того же уровня (если требуется), и установления долговременного ключа связи и (исходного) сеансового ключа. SME может быть реализован на канале сигнализации ( Для сетей, которые поддерживают UNI Signaling 4.0 Security Addendum [4] или PNNI Signaling 1.0 Security Addendum) или по каналу передачи данных, который заранее установлен или находится в процессе установления.

Первый упомянут как " SME, основанный на сигнализации",а последний как " внутриполосный SME "

Как отмечалось ранее, основанный на сигнализации SME используется в сетях, которые поддерживают UNI Signaling 4.0 Security Addendum [4] или the PNNI Signaling 1.0 Security Addendum [5]. Поддержка для B-ICI и других протоколов сигнализации в настоящее время не определена. Пример использования SME в сети, которая поддерживает защитные приложения показан на рисунке 7 (где " UNI 4.0 + sec " и " PNNI 1.0 + sec " обозначают связи,которые осуществляют приложения защиты UNI и PNNI ). В этом случае, конечные системы (с агентами безопасности) прикрепляют SSIE к сигнализационному сообщению, и поскольку сеть устанавливает запрос, SSIE передается без модификации.

 

 

Рисунок 4.Единая сеть,поддерживающая SME,основанный на сигнализации.

Более вероятный сценарий - тот,который содержит элементы сети, неподдерживающие основанный на сигнализации SME.

В этом случае, вызывающая конечная точка приложена к сети, которая поддерживает основанный на сигнализации SME .

Инициализизация агента защиты в этой конечной точке поставляет информацию защиты наряду с сигнализационным сообщением, и сообщение проходит частную сеть. Когда сообщение достигает границы UNI 4.0 + коммутатора, это сообщается через туннель виртуального пути к удаленному коммутатору, который также поддерживает основанный на сигнализации SME .Хотя сеть общего пользования не поддерживает основанный на сигнализации SME , VP туннель позволяет двум граничным коммутаторам прямо сообщать о друг друге, и следовательно, позволяют SME проходить сеть общего пользования. Так как удаленный коммутатор содержит агента защиты, который закрывает защищенное соединение, другие элементы сети не обязательно должны поддерживать основанный на сигнализации SME.

Если ни один из элементов сети (что не ожидается) не поддерживат основанный на сигнализации SME , то вместо этого может использоваться внутриполосный SME протокол введенный ранее.

В этом случае, вызывающая конечная система инициирует запрос на установку связи, и ,как обычно, запрос передается в эту конечную систему. По мере продвижения запроса на установку связи, агенты защиты пополняют сигнализационное сообщение защищенной информацией, которая пропускается сетями (потому что они не распознают информационную часть служб безопасности). В результате, последующие агенты защиты не видят защищенную информацию в сообщении запроса на установку. Поскольку сигнал подтверждения подключения передается назад от названной конечной системы к вызывающей конечной системе,агенты безопасности пополняют сигнализационное сообщение информацией защиты, которая также пропускается сетями. Однако, поскольку сеть передает подтверждение подключения, отдельным путем строится контур пользовательского виртуального канала. Когда пользовательский VC соединяет двух агентов защиты, передача данных из конечных систем блокируется, и SA выполняет роль SME протокола в пределах этого виртуального канала.

Замечание: Для звонков в режиме телефона, переговорный путь обычно строится (речевой траффик это позволяет) в обоих направлениях, кроме завершительного обмена .

При завершающем обмене путь к указанной стороне не строиться. Обратный путь строится, чтобы вызывающий абонент смог слышать сигналы или сообщения ,которые могут появляться перед ответом (например, дозвон, перенаправление, занято, " номер,который вы набрали больше не обслуживается ") и избегать обрезание речи, когда вызываемый абонент снимает трубку и говорит ” привет “.. В случае, когда конечная станция запрашивает службы безопасности, не должно получиться так, что эти службы уже действуют,а сообщение о подключении не получено, и SME закончен.

Независимо от использованного SME метода, после того, как SME закончен, OAM потоки могут использоваться сохранения состояния защищенных соединений.

В особенности, OAM ячейки используется для :

- замены дополнительных сеансовых ключей связи для конфиденциальности и целостности данных.

(Заметьте, что исходные сеансовые ключи установливаются в течение SME.)

- поддержания синхронизации машин шифрования,ориентированных на встречный режим работы.

Функции агента безопасности могут быть разбиты на несколько разделов:

- SAsme, те функции агента безопасности, которые взаимодействуют с сигнализации для реализации SME,

- SAservice, те функции агента безопасности, которые предоставляют аутентификацию, проверку целостности, и службы конфиденциальности,

· SApolicy, те функции агента безопасности, которые определяют когда и как должна быть применена защита ,

- SAmisc, оставшиеся функции агента безопасности такие как OAM обработки ячеек.

Это разделение толко наглядно и не подразумевает как реализуется агент безопасности .

 

Назад  Главная страница  Вперед

Hosted by uCoz